This invention generally relates to mapping display data, and more particularly to mapping display data from one or more formats to a shared format.
Collaboration between individuals takes on many forms with face-to-face, telephone calls and e-mails being some of the most ubiquitous. As technology has progressed, individuals have sought to further collaborate by sharing video, voice, whiteboard markup, chat, as well as computer applications. Two common collaboration software products that allow such sharing are Lotus SAMETIME® and Microsoft NETMEETING®. One problem with many current collaboration software products is their platform dependency. For example, Microsoft NETMEETING® only works on systems that use a version of the Microsoft WINDOWS® operating system. Different platforms manage display data differently. This presents a significant obstacle to creating collaboration products that can be used across platforms.
For example, display data includes pixel data for each pixel in the display. Pixel data includes information on the location of the pixel, the color of the pixel, and the depth of the pixel. Various formats are used to represent color information in pixel data. Consequently, to implement the sharing of display data across platforms, pixel data can be converted into a shared format. However, several factors prevent many implementations from efficiently converting pixel data into a shared format. One factor is the need to determine the window that “owns” each pixel in the display area to be converted. A window owns a pixel when it provides pixel data for the pixel.
In a typical windows display environment, windows can have a hierarchical relationship. For example, a parent window can be created that includes within its display space one or more child windows. Child windows can also have one or more child windows of their own. Each window occupies a portion of any ancestor window's (i.e., parent window, grandparent window, etc.) display space. Sibling windows either share the same parent window or have no parent window (i.e., they are displayed on the desktop). Sibling windows are assigned a stacking order. The stacking order determines the order in which sibling windows are drawn, and as a result, which sibling window is “on top” when the display areas for two sibling windows overlap. The size, stacking order, and number of windows are frequently changed by a user. For example, a parent window might be “maximized” to take up an entire display area. Further, a user can select a window partially behind a sibling window, resulting in the selected window being shown on top of the sibling window.
Determining pixel ownership is important, for example, in an X Windows System, since pixel data can be formatted differently for each window in this system. The X Window System is a client-server windowing system in which an “X client” (application) performs processing that includes commands to alter a display. These commands are provided to an “X server” that implements the display alteration (i.e., “serves” the image to a user). The X server resides on the computer with the display, while the X client can reside on any computer in a computer network that includes the computer with the display.
Typical display formats vary by “depth,” i.e., the number of bits used for the pixel data for each pixel, and “visual,” i.e., how the pixel data is to be interpreted. Depth determines the number of possible colors that can be displayed at one time for pixels within a window. For example, pixel data having a depth of eight bits allows up to two hundred fifty-six (28) colors to be displayed simultaneously. In general, the visual determines whether the pixel data is to be interpreted as including the color values or as including one or more indexes into color table(s) that contain the color values. There are six standard types of visuals in an X Window System environment: TrueColor pixel data includes the Red-Green-Blue (RGB) color values encoded in the pixel data, StaticColor and StaticGray pixel data contain an index into a color table containing unchangeable color values, DirectColor pixel data includes three separate index values to look up the RGB color values in three separate modifiable color tables, and GrayScale and PseudoColor pixel data comprise an index into a modifiable color table that contains the color values. The final three visuals allow the values in the one or more color tables to be modified, thereby allowing the actual color displayed for a particular value to be variable. A twenty-four bit TrueColor format is a commonly used format for display data. With this format, the actual value for each color (i.e., Red, Green, and Blue) is represented by a unique eight bit portion of the twenty-four bit value. Numerous systems and applications are configured to support this format. For example, the JAVA® programming language developed by Sun Microsystems supports the twenty-four bit TrueColor format and has been implemented on numerous systems and platforms.
Determining when an area of the display has been modified is another factor that prevents efficiently converting display data. For example, an X server provides a display-based event stream and query mechanism to inform an application of a user-initiated event, thereby allowing the application to interact with the user. An application can specify which events it desires to be notified about, and take appropriate action based on the event. Common events include creating/destroying a window, resizing a window, changing the stacking order of a window, etc. However, an X server does not provide an event that signals when an area of a display has been modified. Consequently, in order to share a display area with another system, display data for the entire display area must be continually copied and monitored.
Several approaches have been provided to implement application sharing including sharing display data in an X Windows System. For example, a separate viewer program can be executed. This approach is used in the Virtual Network Computing (VNC) solution provided by AT&T Laboratories. Alternatively, the communications between multiple X clients and X servers can be multiplexed. This approach is used in the XMX solution developed by Brown University. However, both these approaches require the application to be started inside the X server in order to share the application. This means that a user needs to recognize a desire to share or remotely access an application before it is launched. This limitation can degrade productivity when an application cannot be readily restarted. Another approach for application sharing is to add functional extensions to the X server. However, the use of extensions severely limits the number of platforms on which this approach can be readily implemented. Categorizing and mapping each pixel is another performance problem for XWindows based sharing approaches that seek to share display data using external functions (i.e., no proxies, just standard X11 protocol) when the various windows within the shared display area may use different display formats to represent the display data. External approaches that attempt to address the use of different display formats fail to provide an efficient solution for mapping pixel data that takes advantage of the hierarchical relationship of windows.
As a result, there exists a need for a way to efficiently map display data for a display area in which multiple windows are present and more than one display format is used to represent the display data.